home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1946 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  1.6 KB

  1. Path: netnews.research.nokia.com!wikman
  2. From: wikman@falcon.research.nokia.com (Johan Wikman)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Why use private class members instead of protected?
  5. Date: 14 Jan 1996 08:05:33 GMT
  6. Organization: Nokia Research Center
  7. Message-ID: <WIKMAN.96Jan14100533@falcon.research.nokia.com>
  8. References: <30F4AB49.6ABB@sierra.net>
  9.     <30F50874.15FB7483@intellektik.informatik.th-darmstadt.de>
  10.     <4d3q07$n8o@geraldo.cc.utexas.edu>
  11.     <30F61CAC.2781E494@intellektik.informatik.th-darmstadt.de>
  12. NNTP-Posting-Host: falcon.research.nokia.fi
  13. In-reply-to: Enno Sandner's message of Fri, 12 Jan 1996 09:32:44 +0100
  14.  
  15.  
  16. In article <30F61CAC.2781E494@intellektik.informatik.th-darmstadt.de> Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> writes:
  17.  
  18.    However an accessor/mutator pair like
  19.  
  20.            void MyClass :: set_data(const DataType&) { ... }
  21.            DataType MyClass :: get_data() const { return _data; }
  22.  
  23.    completely avoids this sort of problems. If the 'DataType' uses some 
  24.    technique to speed up copying (for example ref-counting) the overhead 
  25.    is minimal.
  26.  
  27. I think you only change the problem into something else. Now if you
  28. ever choose to change the representation of '_data' you face the
  29. problem of converting a DataType to and from whatever type '_data'
  30. is. The problem is still there, it has only changed shape.
  31.  
  32. In my opinion it fairly seldom makes sense to provide accessor/mutator
  33. functions to the data members of a class. In fact, I get suspicious
  34. when a class reminds you of a data repository instead of reminding you
  35. of something that provides behaviour.
  36.  
  37.     Johan
  38. --
  39. johan.wikman@research.nokia.com
  40.